Several paradigms of database organisation are known. Data are provided in the form of objects, each object being a piece of data, and gathering a plurality of attributes relative to said object, each attribute containing a name or type and a value.
One of the most used paradigms is relational database, RDB. In relational database, data are stored in tables, also named relations. The names of the columns being the names of the attributes, each object corresponds to a row in a table, said row containing the values of the corresponding attributes.
Relational database are well known for a long time. They have proven to be a powerful way of storing data. They are very used all over the world, and a lot of tools and systems are available to manage such databases. Also a lot of practitioners are educated to create, manage or use such databases and associated tools. For example, the SQL query language is well known and used.
However, the relational paradigm appears to be somewhat limited when dealing with complex organizations of data, and new paradigms have been developed to provide tools with more elaborated semantic to express said complexity. X500 is one of these alternative paradigms that tend to meet the favour of database owners and users. X500 allows a richer syntax when describing the organization of a database. X500 is standardized. X500 provides a more user friendly approach that allows the manager of a database to easily describe the structure of its data. It is also possible to design an X500 specification using the know language UML.
Both RDB and X500 worlds have their own advantages, and it would be advantageous to take benefit from the two worlds. It is then of interest to be able to provide a mapping of an X500 data model to a relational database model.
Other constraints, coming from the fact that the solution, bound to be used by telecom applications that need time performances and that work on big amount of data, are the ability to provide performances equivalent to the direct RDB use, and the optimization, as most as possible, of the whole database size.
WO96/07147 (U.S. Pat. No. 6,052,681) describes a solution to this problem. However, X500 information is integrated into the RDB tables. This causes a big overhead on database size. Furthermore one X500 access triggers many database access and thus degrades performances.
In US 2006/0173873 a hierarchical/relational translation system is described which uses virtual directory services.
In U.S. Pat. No. 6,823,338 a method for mapping X500 access control data to a relational data base is described.
In U.S. Pat. No. 5,333,317 a method of searching in an X500 database is described.
However none of these methods satisfies all of the given constraints.